Upper-level protocol authentication

ABSTRACT

A method for authenticating communication traffic includes receiving a first message, sent over a network from a source address, requesting information from a server in accordance with a higher-level protocol. A challenge is sent to the source address in reply to the first message, in accordance with the higher-level protocol. A second message is received from the source address following the challenge, and the legitimacy of the source address is assessed by determining whether the second message contains a correct response to the challenge.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication 60/539,327, filed Jan. 26, 2004, and is related to thefollowing co-pending applications: U.S. patent application Ser. No.09/929,877, filed Aug. 14, 2001; U.S. patent application Ser. No.10/232,993, filed Aug. 29, 2002; U.S. patent application Ser. No.10/251,912, filed Sep. 20, 2002; and PCT Patent ApplicationPCT/IL02/00996, filed Dec. 10, 2002. All of these related applicationsare assigned to the assignee of the present patent application and areincorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates generally to computer networks, andspecifically to methods and systems for protecting against denial ofservice and worm attacks in computer networks.

BACKGROUND OF THE INVENTION

In a Denial-of-Service (DoS) attack, an attacker bombards a victimnetwork or server with a large volume of message traffic. The trafficoverload consumes the victim's available bandwidth, CPU capacity, orother critical system resources, and eventually brings the victim to asituation in which it is unable to serve its legitimate clients.Distributed DoS (DDoS) attacks can be even more damaging, as theyinvolve creating artificial network traffic from multiple sourcessimultaneously.

In order to launch an, effective DDoS attack, an attacker typicallyattempts to control a large number of servers on the Internet. Oneapproach to gaining such control is to use “worms,” which are maliciousprograms that self-replicate across the Internet by exploiting securityflaws in widely-used services. Worm infections are often invisible tothe user of an infected computer, and the worm may copy itself to othercomputers independently of any action taken by the computer user. Aftertaking control of a computer, the worm often uses the computer toparticipate in a DDoS attack, without any knowing collaboration on thepart of the computer user. Infected computers that participate in thissort of mass malicious activity are referred to herein as “zombies.”

The present invention will be more fully understood from the followingdetailed description of the embodiments thereof, taken together with thedrawings in which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that schematically illustrates a computernetwork system, in accordance with an embodiment of the presentinvention;

FIG. 2 is a flow chart that schematically illustrates a method forprotecting against DDoS attacks, in accordance with an embodiment of thepresent invention; and

FIG. 3 is a message flow diagram that schematically shows details of amethod for authenticating a source of incoming packet traffic, inaccordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Many DDoS attacks use “spoofed” IP packets—packets containing a bogus IPsource address—making it difficult for the victim network to identifythe source of the attack. In response to this problem, theabove-mentioned related applications describe methods that may be usedto determine whether the IP source address of an incoming packet isauthentic or spoofed. Traffic from authentic IP addresses may then bepassed on to its intended destination, while packets with spoofedaddresses are blocked.

Zombies, however, may have legitimate IP addresses (belonging to theinfected source computer), and anti-spoofing measures may therefore failto filter-out the packets generated by such zombies during a DDoSattack. Thus, in a typical attack, many zombies may succeed inestablishing TCP connections with a victim server, and then may usethese connections to bombard the server with messages, such as HTTPrequests.

Embodiments of the present invention provide methods for resisting thissort of attack, by distinguishing legitimate messages from messages sentby zombies. For this purpose, some embodiments of the present inventionenable a network guard device to challenge sources of incoming packettraffic so as to determine whether the sources comply fully withhigher-level communication protocols, such as HTTP (including featuresof HTML) or DNS, which operate above the transport layer (typically TCPor UDP). Failure of a computer at a given source IP address to complywith the higher-level protocol indicates that the source may be azombie, and incoming packets from this source are therefore blocked.

FIG. 1 is a block diagram that schematically illustrates a computernetwork system 20, in accordance with a preferred embodiment of thepresent invention. A Web server 22 communicates with clients 24 via awide-area network (WAN) 26, typically the Internet. To prevent DDoSattacks on server 22, a guard device 27 intercepts incoming HTTP requestpackets from network 26 that are addressed to server 22. Guard device 27comprises a guard processor 28, which performs the various protectionand authentication methods described herein, and a network interface 29,which communicates with other components of system 20 and with WAN 26.The guard processor checks the IP source address of each packet that itintercepts against reference values stored in a, database 30 or otherdata structure. Methods for generating these reference values—indicatingwhich requests are legitimate, and which may have originated fromspoofed IP addresses or from zombies—are described further hereinbelow.The guard processor blocks illegitimate requests from passing through toserver 22.

The configuration and operation of guard device 27 are shown anddescribed herein by way of example, and alternative configurations andmodes of operation will be apparent to those skilled in the art. Forexample, rather than being connected in-line with server 22, as shown inFIG. 1, guard device 27 may be connected in other configurations, forexample, by a “lollipop” connection to a router (not shown) thatforwards packets to server 22. Alternatively, functions of the guarddevice may be integrated into the router or server or into other networkequipment, such as a firewall. These and other possible operationalconfigurations of the guard device are described in the above-mentionedrelated applications. Note that although guard device 27 is shown anddescribed herein as protecting a single server 22, in practice one ormore guard devices of this sort may be deployed to protect a group ofcomputers, such as a cluster of servers or an entire LAN. Additionaldeployment scenarios for the guard device(s) (not necessarilyzombie-based) are described in the above-mentioned related applications.

Typically, guard device 27 comprises a general-purpose computer, whichis programmed in software to carry out the functions described herein.The software may be downloaded to the computer in electronic form, overa network, for example, or it may alternatively be supplied to thecomputer on tangible media, such as CD-ROM. Further alternatively, guarddevice 27 may be implemented in dedicated hardware logic, or using acombination of hardware and software elements.

FIG. 2 is a flow chart that schematically illustrates a method that iscarried out by guard processor 28 for protection against DDoS attacks,in accordance with an embodiment of the present invention. The guardprocessor may perform its packet screening and verification functions atall times, or it may alternatively filter packets only under stressconditions, in which a DDoS attack on server 22 is suspected. In orderto determine whether an attack may be in progress, guard processor 28intercepts incoming traffic via network interface 29 and monitorsselected statistical characteristics of the incoming traffic that isdirected to server 22, at an attack detection step 50. For example, theguard processor may use one or more of the following criteria to detecta zombie-based DDoS attack:

-   Number and distribution of source IP addresses—A sudden change, such    as an increase in the number of different source IP addresses    attempting to communicate with the server, may be indicative of an    attack.-   Distribution of user agents specified in HTTP requests—The agent    field in the HTTP request is optional, but it is usually used to    specify the type of browser submitting the request. A sudden change    in the distribution of agents may indicate that a large fraction of    the requests are being submitted by zombies, which specify a    particular agent as dictated by the malicious program that is    controlling them. (In order to limit the amount of malicious traffic    that can reach server 22, guard processor 28 may optionally    determine, in the absence of an attack, a baseline percentage    distribution of HTTP requests among the different possible user    agents, and may then simply block all traffic specifying a    particular user agent that is in excess of the baseline percentage    for that agent.) Similarly a sudden change in the number of requests    without the agent field, or with a bogus agent field, may be    indicative of a zombie attack.-   Occurrence of other regular patterns in the incoming traffic—Zombies    tend to send many identical packets repeatedly, at regular    intervals. Detection of this sort of repeating pattern may be    indicative of an attack. Other attack detection criteria will be    apparent to those skilled in the art. Additional criteria (not    necessarily zombie-based) are described in the above-mentioned    related applications.

As long as no attack in progress, guard processor 28 typically permitsincoming packets to pass through to server 22, at a packet delivery step52. On the other hand, when an attack is believed to be in progress,guard processor 28 filters some or all of the incoming traffic, at afiltering step 54. For this purpose, the guard processor maintains arecord in database 30 of IP source addresses that are known to belegitimate (because of past communications with these source addresses,as described below). Database 30 may also contain a “blacklist” ofaddresses that are believed to be malicious. Guard processor 28 checksthe source address of each incoming packet against the database record,at a source address checking step 56. If the address appears on thelegitimate list, the packet is passed on to server 22 at step 52.(Additionally or alternatively, if the address appears on the blacklist,the packet may be discarded.)

If the IP source address of the incoming packet is unknown, guardprocessor 28 tests the address to determine whether it is legitimate orspoofed, at a spoofing check step 58. Typically, the guard processorinitiates a challenge/response routine, by sending a packet (the“challenge”) containing certain information to the IP source address ofthe incoming packet via interface 29. The guard processor then checksthat the response packet received from the IP source address containsappropriate matching information, at an IP authentication step 60.Various challenge/response methods that may be used for this purpose aredescribed in the above-mentioned U.S. patent application Ser. No.10/232,993. If the IP address is found to be bogus, the incoming packetis discarded, and the address may be entered in the blacklist indatabase 30, at a packet discard step 62.

FIG. 3 is a message flow diagram, which shows details of spoofing checkstep 58, in accordance with one embodiment of the present invention. Inthis example, the TCP three-way handshake is used to authenticate thesource IP address. The message flow begins when guard processor 28intercepts a TCP SYN packet sent from an IP source address that does notyet appear in database 30. The SYN packet has a certain packet sequencenumber (s#), in accordance with TCP convention. The guard processorsends back a TCP SYN-ACK packet to the IP source address of the SYNpacket via interface 29. The SYN-ACK packet contains an encoded cookie(c#), which is encoded in the sequence number (s#) of the packet. Anysuitable method of cookie generation that is known in the art may beused for this purpose and for generating cookies in other embodiments ofthe present invention. In one embodiment, a hash generator implements ahash function for mapping packet attributes, such as the IP sourceaddress and port, to cookies. The hash generator calculates a hashvalue, which is used as a key for indexing a cookie table comprising aset of random cookies. The random cookie values are replaced after useto prevent an attacker who succeeds in discovering a legitimate cookievalue from re-using the cookie.

If guard processor 28 then receives a proper TCP ACK packet back fromthe same IP source address, identified by the proper sequence number andcookie, the guard processor is able to ascertain that the source addressis legitimate, rather than spoofed. (Note, however, that the guardprocessor still does not know whether the computer at this sourceaddress is a zombie or not). Alternative anti-spoofing methods aredescribed in the above-mentioned related applications.

Returning now to FIG. 2, after guard processor 28 verifies that the IPsource address of a given packet is authentic at step 60, it may go onto test the legitimacy of the higher-level software running on thesource computer, at a protocol challenge step 64. In the presentembodiment, it is assumed that guard device 27 is protecting a Webserver (as shown in FIG. 1), and that the guard processor hasintercepted a HTTP request from an unknown source address. Step 64 testswhether the HTTP request was generated by a legitimate browser,complying with all the requirements of HTTP. Based on this test, theguard processor determines whether the source computer is legitimate ora zombie, at a browser legitimation step 66. An exemplary test of thissort is described below with reference to FIG. 3.

The test used at step 64 is based on sending a HTTP response, containinga HTML directive (the challenge), back to the IP source address of theincoming HTTP request, and checking the next reply returned from this IPaddress. For the most part, zombies are driven by relatively simpleprograms, which may be capable of emulating certain basic aspects ofHTTP, but do not implement all the specified functions of HTML (asrequired, for example, by IETF RFC 1866 and the applicable HTMLspecification, such as HTML 4.0). Therefore, if the source addressreturns the reply that is expected in compliance with the protocol,guard processor 28 may conclude that the computer at the IP sourceaddress is legitimate, and is not a zombie. In this case, guardprocessor 28 adds the IP address to the list of legitimate addresses indatabase 30, at an address approval step 68. Packets from this addressmay now be delivered to server 22 at step 52. Otherwise, if the computerat the IP source address failed to respond to the challenge or respondedincorrectly, the incoming packet is discarded at step 62, and its IPsource address may be added to the blacklist.

FIG. 3 illustrates one type of test that may be used at step 64. In thisexample, it is assumed that after the source computer on network 26establishes its TCP connection with guard device 27 (at step 58), itsubmits a HTTP request for a certain URI on server 22, for example, GET/index.html. As noted above, the request may also specify other HTTPfields, such as the user agent. The guard processor intercepts thisrequest via interface 29 and returns a response, which redirects thesource computer to refresh its browser with a new URI (identified inFIG. 3 as URI′). Requests directed to the URI′ will also be interceptedby the guard processor, but URI′ contains information, such as a cookie,that will enable the guard processor to identify the source of therequest. For example, the guard processor may return a responsecontaining the HTML directive: <META HTTP-EQUIV=″Refresh CONTENT=″1;URL=cookie.index.html″>, wherein “cookie” is a unique string generatedby the guard processor.

Normally, this response should cause the browser on the source computerto open a new TCP connection with guard processor 28, and then resubmitits HTTP request to URI′, i.e., to “cookie.index.html”. (To open a newTCP connection, the source computer again sends a SYN packet, receives aSYN-ACK from the guard or the target, and then sends an ACK. Thesethree-way exchanges associated with the HTTP GET URI′ and the final HTTPGET URI are omitted from FIG. 3 for the sake of simplicity.) Uponreceiving this new request, the guard processor is able to conclude thatit is communicating with a legitimate browser on the source computer,and adds the IP address of the source computer to its approved list indatabase 30. The guard processor then redirects the source computer onceagain to the original URI=index.html. As a result, the source computerwill attempt to open yet another TCP connection with server 22. Thistime, however, the guard processor will recognize the IP source addressof the TCP SYN packet from the source computer as legitimate, and willpass the packet through to server 22. The server and source computer maythen proceed to communicate in the normal fashion.

On the other hand, if the original HTTP request from the source computerwas sent by a zombie, rather than by a legitimate browser, the sourcecomputer will be unable to parse the HTTP response sent back by guardprocessor 28. Therefore, the source computer will not resubmit itsrequest to “cookie.index.html”. Rather, the source computer will, in alllikelihood, simply continue submitting further requests to the originalURI. Since the guard processor will not have authenticated the IP sourceaddress, it will not permit these requests to pass through to server 22.Furthermore, upon receiving multiple, repeated requests of this sort,the guard processor may conclude that the source of the requests is azombie, and will then add the IP source address to the blacklist.

Various other methods may be used at step 64 in order to verify that alegitimate browser is operating at a given IP source address. Thesemethods may be based on encoding cookies in other parts of the HTTPresponse sent by guard processor 28, or by testing the source computerfor compliance with other aspects of the applicable protocols, such asRFC 1866 or RFC 2616. For example, the guard processor may redirect thebrowser on the source computer by replying to the initial HTTP requestwith a HTTP redirect response (status code 307), redirecting the clientbrowser to URI′, containing the encoded cookie.

Alternatively or additionally, the response sent by the guard processormay test whether the original HTTP request sent by the source computerwas submitted in response to instructions of a human operator of thesource computer. For example, the response may cause the browser on thesource computer to display an image or play a sound, and prompt thehuman operator to type a corresponding word into the computer. Theresponse causes the source computer to return the word that the user hastyped, thus permitting the guard processor to verify the presence of ahuman user operating the browser on the source computer. A zombie,clearly, will fail this test. Challenge/response routines of this sort,for verifying the presence of a human user on the source computer, aredescribed further in the above-mentioned U.S. patent application Ser.No. 09/929,877.

Although the embodiment described above makes reference particularly toHTTP and its use in conjunction with Web server 22, the principles ofthe present invention are generally applicable to authentication ofincoming traffic using higher-level protocols of other types. In thecontext of the present patent application, the term “higher-levelprotocol” refers to protocols operating above the transport layer (layer4), as defined by the well-known Open Systems Interconnection (OSI)Reference Model. Internet traffic generally uses TCP or UDP as itstransport-layer protocol. Higher-level protocols that may operate overTCP or UDP include (but are not limited to) HTTP, FTP, DNS, RTP,POP/SMTP, SNMP, Usenet, Telnet and NFS. These protocols are generallyclassified as “presentation-layer” protocols, although this is a looseclassification, and these protocols are also often referred to as“application-layer” protocols.

In any case, when clients attempt to communicate with a server accordingto any higher-level protocol such as these, a guard device protectingthe server may use a challenge/response technique based on therequirements of the specific protocol in order to authenticate thesources of the communications. For example, the above-mentioned U.S.patent application Ser. No. 10/251,912 describes methods and devices fordistinguishing between spoofed and authentic DNS requests. Many otherhigher-level protocols (in addition to those listed above) are known inthe art, and are amenable to authentication by the methods of thepresent invention.

Furthermore, although the embodiments described above are directedmainly to processing IP packet traffic sent over the Internet, theprinciples of the present invention are similarly applicable to networksof other types, using other protocol families. It will thus beappreciated that the embodiments described above are cited by way ofexample, and that the present invention is not limited to what has beenparticularly shown and described hereinabove. Rather, the scope of thepresent invention includes both combinations and subcombinations of thevarious features described hereinabove, as well as variations andmodifications thereof which would occur to persons skilled in the artupon reading the foregoing description and which are not disclosed inthe prior art.

1. A method for authenticating communication traffic, comprising:receiving a first message, sent over a network from a source address,requesting information from a server in accordance with a higher-levelprotocol; in reply to the first message, sending a challenge to thesource address in accordance with the higher-level protocol; receiving asecond message from the source address following the challenge; andassessing legitimacy of the source address by determining whether thesecond message contains a correct response to the challenge.
 2. Themethod according to claim 1, wherein the correct response is determinedby a specification of the higher-level protocol.
 3. The method accordingto claim 1, wherein sending the challenge comprises encoding informationin a reply message sent to the source address in reply to the firstmessage, and wherein assessing the legitimacy comprises ascertainingwhether the second message contains the encoded information.
 4. Themethod according to claim 3, wherein the higher-level protocol comprisesHTTP, and wherein encoding the information comprises sending the replymessage so as to redirect a browser at the source address to a URI thatcontains a cookie.
 5. The method according to claim 1, wherein assessingthe legitimacy comprises verifying that the second message was generatedby a computer at the source address responsively to an input made to thecomputer by a human operator.
 6. A method for processing communicationtraffic, comprising: monitoring the communication traffic that is sentover a network to a destination address; determining a baselinecharacteristic of the communication traffic while a DDoS attack is notin progress; detecting a deviation from the baseline characteristic thatis indicative that at least some of the communication traffic has beensent by zombies having legitimate addresses on the network; andresponsively to detecting the deviation, filtering the communicationtraffic so as to remove at least some of the communication traffic sentby the zombies.
 7. The method according to claim 6, wherein detectingthe deviation comprises detecting an increase in a number of differentsource addresses from which the communication traffic has originated. 8.The method according to claim 6, wherein monitoring the communicationtraffic comprises reading contents of incoming data packets sent fromthe legitimate addresses on the network in accordance with ahigher-level protocol, and wherein detecting the deviation comprisesdetecting a pattern in the contents.
 9. Apparatus for authenticatingcommunication traffic, comprising: a network interface, which isarranged to communicate with a network; and a processor, which iscoupled to the network interface and is arranged to receive a firstmessage sent over the network from a source address, requestinginformation from a server in accordance with a higher-level protocol, tosend a challenge to the source address in reply to the first message, inaccordance with the higher-level protocol, to receive a second messagefrom the source address following the challenge, and to assesslegitimacy of the source address by determining whether the secondmessage contains a correct response to the challenge.
 10. The apparatusaccording to claim 9, wherein the correct response is determined by aspecification of the higher-level protocol.
 11. The apparatus accordingto claim 9, wherein the processor is arranged to encode information in areply message sent to the source address in reply to the first messageand to assess the legitimacy of the source address by ascertainingwhether the second message contains the encoded information.
 12. Theapparatus according to claim 11, wherein the higher-level protocolcomprises HTTP, and wherein the processor is arranged to send the replymessage so as to redirect a browser at the source address to a URI thatcontains a cookie.
 13. The apparatus according to claim 9, wherein theprocessor is arranged to verify that the second message was generated bya computer at the source address responsively to an input made to thecomputer by a human operator.
 14. Apparatus for processing communicationtraffic, comprising: a network interface, which is arranged tocommunicate with a network; and a processor, which is coupled to thenetwork interface and is arranged to monitor the communication trafficthat is sent over the network to a destination address, to determine abaseline characteristic of the communication traffic while a DDoS attackis not in progress, to detect a deviation from the baselinecharacteristic that is indicative that at least some of thecommunication traffic has been sent by zombies having legitimateaddresses on the network, and to filter the communication trafficresponsively to detecting the deviation, so as to remove at least someof the communication traffic sent by the zombies.
 15. The apparatusaccording to claim 14, wherein the processor is arranged to detect anincrease in a number of different source addresses from which thecommunication traffic has originated.
 16. The apparatus according toclaim 14, wherein the processor is arranged to read contents of incomingdata packets sent from the legitimate addresses on the network inaccordance with a higher-level protocol and to detect a pattern in thecontents.
 17. A computer software product for authenticatingcommunication traffic, the product comprising a computer-readable mediumin which program instructions are stored, which instructions, whenexecuted by one or more processors, cause the one or more processors toreceive a first message sent over a network from a source address,requesting information from a server in accordance with a higher-levelprotocol, to send a challenge to the source address in reply to thefirst message, in accordance with the higher-level protocol, to receivea second message from the source address following the challenge, and toassess legitimacy of the source address by determining whether thesecond message contains a correct response to the challenge.
 18. Theproduct according to claim 17, wherein the correct response isdetermined by a specification of the higher-level protocol.
 19. Theproduct according to claim 17, wherein the instructions cause the one ormore processors to encode information in a reply message sent to thesource address in reply to the first message and to assess thelegitimacy of the source address by ascertaining whether the secondmessage contains the encoded information.
 20. The product according toclaim 19, wherein the higher-level protocol comprises HTTP, and whereinthe instructions cause the one or more processors to send the replymessage so as to redirect a browser at the source address to a URI thatcontains a cookie.
 21. The product according to claim 17, wherein theinstructions cause the one or more processors to verify that the secondmessage was generated by a computer at the source address responsivelyto an input made to the computer by a human operator.
 22. A computersoftware product for processing communication traffic, the productcomprising a computer-readable medium in which program instructions arestored, which instructions, when executed by one or more processors,cause the one or more processors to monitor the communication trafficthat is sent over a network to a destination address, to determine abaseline characteristic of the communication traffic while a DDoS attackis not in progress, to detect a deviation from the baselinecharacteristic that is indicative that at least some of thecommunication traffic has been sent by zombies having legitimateaddresses on the network, and to filter the communication trafficresponsively to detecting the deviation, so as to remove at least someof the communication traffic sent by the zombies.
 23. The productaccording to claim 22, wherein the instructions cause the one or moreprocessors to detect an increase in a number of different sourceaddresses from which the communication traffic has originated.
 24. Theproduct according to claim 22, wherein the instructions cause the one ormore processors to read contents of incoming data packets sent from thelegitimate addresses on the network in accordance with a higher-levelprotocol and to detect a pattern in the contents.
 25. Apparatus forauthenticating communication traffic, comprising: means for receiving afirst message sent over a network from a source address, requestinginformation from a server in accordance with a higher-level protocol;means for sending a challenge to the source address in reply to thefirst message, in accordance with the higher-level protocol; means forreceiving a second message from the source address following thechallenge; and means for assessing legitimacy of the source address bydetermining whether the second message contains a correct response tothe challenge.
 26. Apparatus for processing communication traffic,comprising: means for monitoring the communication traffic that is sentover a network to a destination address; means for determining abaseline characteristic of the communication traffic while a DDoS attackis not in progress; means for detecting a deviation from the baselinecharacteristic that is indicative that at least some of thecommunication traffic has been sent by zombies having legitimateaddresses on the network; and means for filtering the communicationtraffic responsively to detecting the deviation, so as to remove atleast some of the communication traffic sent by the zombies.